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REMARKS 



Claims 1-4, 6, 8, 9, 11, 12, and 14-20 were rejected as being 
unpatentable over Jordan in view of Garcia. Claims 7, 10, and 13 
were rejected as being unpatentable over Jordan in view of Garcia 
in view of Bertis. Applicant requests reconsideration. 

Independent claims 1, 8, and 12 were amended to include the 
purpose of generating forwarding and routing tables in a cache, and 
to change "routing" to "forwarding and routing", being more 
particular. New Claim 21 claims the specific association as 
transmitted and the relative unilateral communication so that 
random citations to prior art elements without such association and 
communication would be largely irrelevant. 

Claim 19 was amended to depend on new dependent claim 21, so 
that, claim 1 claims the specific association and relative 
communication, with claim 21 claiming that this specific 
association of information is unilaterally communicated when 
transmitted, with claim 19 depending on claim 21, and with claim 19 
claiming the distal table building application of such specific 
association of routing information that is unilaterally 
communicated, relative to those associations and respective caches, 
for the purpose of building distal forwarding and routing tables. 
Applicant now responds by first repeating the prior response, and 
then addresses the examiner's rebuttals at the end of these 
remarks . 
/// 
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From the previous Amendment: 

"a) The examiner states that claim 1 does not reference the tri- 
reference association. Anyone skilled in the art must realize that 
in order to send a message to a destination through the web, the 
destination IPA must be included. The tri-ref erenced information 
includes the originating URL, the source IPA, and the destination 
IPA. That is, the routing information sent must necessarily include 
the originating URL, the source IPA, and the destination IPA. 

b) The examiner states that Jordan transmits routing information 
(such as source address, destination address, forwarding address, 
next hop address as disclosed upon request) . What is strikingly 
missing from this list is the necessary originating URL. 

c) The examiner states that transmitting to one destination is not 
broadcasting and that claim preambles do not limit the claims. If 
the preamble is not a limitation, then the reference to 
broadcasting in the preamble, respecting claim 1, seems misplaced. 
Surely the communication to one destination cache is a minimal, 
point-to-point broadcast, but a broadcast nonetheless. Claims 11 
and 14 particularly claim repeating the communication, which 
perfects a wide-area broadcast. Also, the destination can build a 
forwarding and routing table from the receipt of a plurality of 
routing information. Broadcasting and table maintenance are the 
uses of the claimed tri-ref erence communication. Applications and 
uses are spelled out in the preamble, not as limitations, but as 
uses and applications. While uses and applications are not recited 
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element limitations, they nonetheless go to obviousness, in that, 
the problem solved is relevant, to wit, building a URL- to-distal 
cache routing table through broadcasting. Hence, applicant's 
discussion as to obviousness and the problem solved brings in 
discussion of broadcasting for forming the distal routing table. 

Applicant devised tri-ref erence routing information to solve 
the prior art problem. The tri-ref erence routing information 
communication is the solution, to solve the problem of distal table 
maintenance. It this regard, Jordan and Garcia have no commonality 
with which to arrive at the present invention. Communication of 
routing information by Jordan and the maintenance of table in 
Garcia are not related in any regard, and the combination of them 
does not suggest the invention in any regard. The examiner has 
simply taken isolated features and combined them based upon 
forbidden hindsight reconstruction. Jordan does not communicate the 
tri-ref erence information. And Garcia does not receive the tri- 
ref erence information nor use tri-ref erenced communicated routing 
information to maintain tables. 

d) The examiner first indicated that the claims do not recite a 
table. Hence, claims 19 and 20 were added. Applicant is claiming a 
method of communicating tri-referenced routing information that can 
be broadcast and that can be used to build routing tables in 
receiving distal caches. The examiner states that Garcia discloses 
broadcasting the routing update messages comprising routing 
information. Yet the examiner did not recite what exactly is that 
information, which particularly relates to Internet Protocol packet 
routing in the case of Garcia. Furthermore, Garcia does not 
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communicate tri -referenced routing information that includes an 
originating URL. Both Jordan and Garcia do not communicate tri- 
referenced routing information and both particularly do not 
communicate the originating URL. Without source IPA, originating 
URL, and the destination IPA, combined as routing information, 
which may incidentally be wide-area broadcast and used to build 
routing tables, Jordan and Garcia cannot possibly suggest the claim 
inventions . 

e) The examination's inability to recognize the invention, led the 
applicant to assist the examiner though the inclusion of claims 19 
and 20 wherein the tri -referenced routing information is actually 
used to build routing tables. Prior to adding new claims 19 and 20, 
routing tables were not claimed. Applicant will assist the examiner 
as necessary to fully gain understanding of the inventions and the 
prior art. 

f) The terms hop, path, link, are well understood by those skilled 
in the art. There is no ambiguity. 

The claims were rejected in part because the claims do not 
recite intended applications of the method steps for broadcasting 
associated routing information or recite arguments used in support 
of non-obviousness. These rejections are misplaced. The examiner 
states, on page 4, "In other words, the features upon which 
applicant relies, (as in applicant's arguments), are NOT recited in 
the rejected claims". This is a common perfunctory rejection often 
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correctly used by examiners in anticipation rejections, but so 
often misplaced in the context of obviousness rejections. 

In claim 1, applicant claims a method of broadcasting, which 
method is executed solely at the proximal cache, AND NO MORE . This 
claim clearly sets the reference perspective as being the proximal 
cache at the proximal IPA. As such, a potential infringer has to 
notice that a proximal cache, so broadcasting, that is merely 
broadcasting without regard to creating a forwarding and routing 
table at a destination, perfects the method and is covered by the 
claim. With this broadcasting method, a routing and forwarding 
table at the destination can then be maintained at a distal cache. 
As such, applicant claims the method of broadcasting only in so far 
as the execution is exclusively performed at the proximal cache. 

There is no requirement that claim 1 also includes language as 
to the intended uses or applications of this broadcasting method or 
requirement that this claim claims the benefits of this 
broadcasting method, as the examiner incorrectly suggests. An 
obviousness determination is focused upon whether or not the 
claimed combination is obvious. The determination of obviousness 
goes to both the solution as in part claimed in claim 1 and the 
problem solved as stated in the argument. As to the solution in 
part, the combination of claim 1 has not been rejected as 
anticipated, but rejected for obviousness. Anticipation can be 
determined by an element-by-element comparison. Applicant did not 
address an anticipation rejection, where elements must be recited 
in the claims and not found in a single prior art reference. If 
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applicant had argued that claim 1 was not anticipated because the 
prior art does not teach a destination routing table in 
combination, then the examiner's assertion would have been correct, 
and the routing table should be recited in the claims. However, the 
rejection is one of obviousness that brings into consideration a 
whole variety of related issues, such as, a long felt need without 
solution, and of course, the prior art problems solved. Surely, the 
examiner would not suggest that the claims must specifically recite 
the number of years that the prior art had such a long felt need, 
or necessarily recite the prior art problems solved, yet these two 
things do support a non-obviousness determination. Arguments that a 
claimed invention is not obvious need not be recited in the claims. 
It is simply enough that the combination not be anticipated, as 
indicated in the present record, and that the combination of claim 
1, not be obvious. It is simply enough that the claimed 
broadcasting method steps in combination not be suggested, yet be 
useful. The reasons why a claim combination would not be obvious 
need not be recited in the claims. The examiner's basis for 
rejection because applicant's arguments are not found in the claims 
is without merit in the present obviousness determination context. 

The claims are patentably distinct as written. New claims 19 
and 20 add another step to claims 1 and 8 respectively of storing 
the association in the destination cache at the destination IPA, 
whereat a forwarding and routing table can be maintained. Hence, 
the use of the claimed combination of the broadcasting method of 
claim 1 then enables the creation of forwarding and routing tables 
at the destination IPA, and hence, enables the migration of routing 
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information containing associations between URLs and source web 
cache IPAs subsequently stored as routing items in forwarding and 
routing tables at destination IPAs. Significantly, the claim 1 
steps provide a method of broadcasting routing information that can 
then be used by other distal caches for accomplishing the migration 
of forwarding and routing tables. Claim 1 claims a broadcasting 
method and not the creation of forwarding tables as now claimed in 
new claims 19 and 20. Surely, this unanticipated and unobvious 
broadcasting method is of some value. 

From a practical perspective, the examiner should realize that 
networks have distributed caches that can be manufactured by 
various entities. Claim 1 only covers a broadcasting cache that is 
the proximal cache, and hence, covers a necessary element to 
forwarding and routing table migration within an entire network. 
Claim 1 covers a necessary novel core of the invention because, 
without this broadcasting of routing information, a distal 
forwarding and routing table cannot be maintained by a proximal 
cache. Hence, claim 1 focuses on a core point of novelty while 
providing clear notice of the scope of the claim. Other systems do 
have caches, and do have forwarding tables, and do have routing 
tables, but do not broadcast tri-ref erenced associated routing 
information. Hence, the focus of claim 1 is directed to a necessary 
point of novelty. The threshold point of novelty is the 
broadcasting of tri-ref erenced associated routing information. This 
broadcasting does not include process steps occurring at the 
destination cache, so that one can determine from claim 1, which 
caches within a network are covered by claim 1, and which ones are 
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not. As such, the process steps of claim 1 are executed only at the 
proximal IPA, give clear notice as to what would infringe, and 
focus the examination of this case. This claim 1 strategy provides 
clear notice, covers a necessary point of novelty, and focuses this 
examination on to that the point of novelty, which is the 
broadcasting method of claim 1. 

As such, the present invention of claim 1 serves to solve the 
problems of maintaining a network of cooperative caches through the 
migration of forwarding and routing tables by broadcasting tri- 
referenced associated routing information. The present invention 
solves the problem of routing table migration by broadcasting from 
a first proximal cache to a second destination cache at a 
destination IPA routing information that associates a URL- Id and a 
third source IPA . These first, second, and third caches are clearly 
referenced in claim 1. The associated information includes a tri- 
referenced destination IPA, originating URL, and a source IPA. This 
association is recited in claim 1. Claim 1 is particularly recited, 
novel, unobvious, and useful. 

The destination cache need not necessarily store the sought 
after web content data, but only maintain routing items that define 
where the web content data may ultimately be located through 
routing and forwarding, and ultimately stored among the cooperative 
caches. The web content data specified by the URL can be 
alternatively cached in and retrieved from a source cache for 
improved distributive web content data caching. As such, the 
present invention solves the problem of maintaining cooperative 
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cache forwarding and routing tables by broadcasting tri-ref erenced 
associated routing information. The tri-ref erenced associated 
routing information including the URL, source IPA, and the 
destination IPA, can then be used to create a forwarding and 
routing table in any arbitrary distal cache, so as to migrate the 
forwarding and routing table information about the cooperative 
caches. This migration occurs without regard to load balancing, 
polling, frequency monitoring, or the mere transmission of URL 
requests from any one cache to another cache as in Jordan. 



Applicant appreciates that many web features are found in 
various methods operating on various caches in cooperative systems, 
and that, the examination can become quickly confused if one is not 
careful to focus on the broadcasting steps of claim 1 in reference 
to any sole proximal cache, as in Jordan. Applicant was well aware 
of this potential problem. To make the examination process as 
focused and as convenient as practicable, claim 1 is directed only 
to the minimal novel broadcasting steps executed by a single lone 
proximal cache, so that, operational steps by any other lone cache, 
such as in Jordan, can be quickly compared for novelty. Does this 
prior art reference, Jordan, teach or suggest a single cooperative 
proximal cache executing these tri-ref erenced associated 
broadcasting steps? This determination is limited in scope to aid 
in the examination process. When viewing Jordan, a like reference 
perspective to a "proximal cache" serves to quickly clarify the 
comparison and highlight the points of novelties. 



/// 
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That is, the examiner should compare apples to apples, and any 
lone cache in Jordan can be compared to the proximal cache of claim 
1. However, because all of Jordan's caches operate in like manner, 
any one cache in Jordan may be used for comparison. In this regard, 
the migration and creation of forwarding and routing tables can be 
had through a unilateral tri-ref erenced associated broadcast 
communication from a broadcasting proximal cache as in claim 1. A 
distal cache can then use this broadcast communication for building 
a forwarding and routing table as recited in claims 19 and 20. For 
example, when the destination cache receives a URL request, the 
request can be routed and forward to the source cache and not the 
originating cache. As such, claim 1 and claim 19 highlight 
respective bifurcated functions for migrating forwarding and 
routing tables. Jordan relies on like caches whereas the proximal 
cache of claim 1 and the distal cache of claim 19 rely on a 
cooperation between differently operating caches, yet another clear 
distinction between Jordan and the present invention. 

Jordan teaches a load-balancing network of like cooperative 
caches that store web content data and maintain caching tables. 
Jordan does not solve the problem of migrating forwarding and 
routing tables about a network of caches. Jordan does not use the 
claim 1 solution of transmitting from a proximal cache to a 
destination cache tri-ref erenced routing information associating a 
URL with a source IPA of an alternative source storing or pointing 
to where the URL's web content data may be subsequently retrieved. 
In so doing, the invention of claim 1 serves to enable the 
migration of the forward and routing information about the 
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cooperative distal caches that can then create forwarding and 
routing tables arbitrarily anywhere in the cooperative network. 

Jordan teaches that when a cache is overloaded by a URL 
request, the URL request is directed to another destination at a 
destination IPA, so that the destination, that may store the web 
content data, can then function as a new alternative source. As 
such, the destination can retrieve the web content data, store it 
locally, and then respond to URL requests for the web content data 
so as to load share. As such, the destination and source are one in 
the same. Jordan does not solve the problem of migrating forwarding 
and routing tables among cooperative distal caches. Jordan does not 
suggests the invented solution of broadcasting to a destination 
distal cache tri-ref erenced routing information associating the 
destination IPA with a URL indicating that web content data can be 
found in an alternative source cache. 

In Jordan, a proximal cache at a proximal IPA receives a 
request for URL web content data from an originator or client 
browser. When the proximal cache at the proximal IPA is overloaded, 
the proximal IPA redirects the original request to a destination 
IPA also storing the web content data. The request is forwarded to 
a destination as an alternative source. The request contains an 
association between the requesting IPA and the URL of the 
originator originally firstly storing the requested web content 
data. Then, the destination cache stores the web content data to 
serve URL requests . The destination retrieves the URL web content 
data, stores it locally, and updates its caching table indicating 
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it has stored this URL web content data. Jordan teaches load 
sharing. Jordan does not teach a method of broadcasting tri- 
referenced routing information, including an association between 
URL- Id and an alternative source of the URL- Id web content data and 
a destination, but rather directs the URL request to an unloaded 
server storing the sought after URL data. Jordan does not teach a 
method of broadcasting an association of a source with a URL to an 
arbitrary destination that can then construct and maintain a 
routing and forwarding table. 

Jordan teaches a load-balancing web content data caching system 
that maintains a logical central directory for locating where 
requested web data is stored, preferably in the least loaded cache. 
(Col 7 lines 60-65) . In Jordan, there is a guarantee that the owner 
indicated in the directory does store the sought after web content 
data. By contrast, the present invention makes no such guarantee, 
as the routing information merely provides a direction through 
which a request could be forwarded or routed until a source cache 
is eventually reached that does store the sought after web content 
data specified in the URL request. The broadcasting of claim 1 
provides the routing information, including the destination IPA, 
the URL, and the source IPA, and not the web content data. 

The present invention provides for the broadcasting of routing 
information from a proximal IPA. The routing information at the 
proximal cache at a proximal IPA location is a tri -referenced 
association associating the destination cache at a destination IPA, 
and a source cache at a source IPA, and the URL. The associated URL 
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request for web content data originally provided at a originating 
URL IPA is an implied fourth location. The physical locations are 
the proximal IPA, source IPA, the destination IPA as particularly 
stated in claim 1, while a fourth location of the original URL IPA 
location is also inferred. This specifically required tri- 
referenced association of the destination IPA, source IPA and URL, 
as recited in claim 1, is essential to understanding the novelty of 
claim 1 that then enables the migration of forwarding and routing 
tables. The destination IPA, originating URL, and source IPA 
association includes routing information associating a source IPA 
and the URL during broadcasting, which then enables the building of 
a forwarding and routing table at the destination distal IPA. 
Jordan does not have this tri-ref erenced association or the 
capability of migrating forwarding and routing information through 
unilateral broadcasting. Jordan does maintain a caching table, 
which can be used to forward URL requests. However, the caching 
table is not maintained by virtue of receiving unilateral broadcast 
tri-ref erenced associated routing information. The caching table is 
not maintained by virtue of receiving unilateral broadcast routing 
information because, in Jordan, at least two of the claimed tri- 
ref erenced IPA locations, if not all three, are the same locations. 
In Jordan, the source and destination are one in the same, which 
receives a request, retrieves the URL data, updates its caching 
table, and becomes the alternative source, and hence, the 
limitation to only caching tables indicating exactly where is 
stored the requested web content data. 



/// 
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In view of the abstract of Jordan, a "request" indicating a 
requester at a requester IPA and indicating the "object", that is 
the requested URL web content data, is "forward" directly to 
another cache, so that the "requests" are shifted, that is, forward 
to another cache also storing the sought after web content data. 
Jordan does not use routing in any regard, as the examiner 
incorrectly suggests. Jordan migrates web content data and forwards 
requests when overloaded. Jordan's shifting by forwarding requests 
perfects load balancing among caches. As such, Jordan maintains a 
directory as a correctly named caching table of all caches storing 
the sought after web content data for forwarding when overloaded. 
That is, all of Jordan's caches are merely source caches sharing 
loads by forwarding requests. There is a difference between a 
caching table and a forwarding and routing table. A caching table 
points directly to alternative source caches having the stored 
data. A forwarding and routing table points to another location 
that may or may not have the stored data, but ultimately indirectly 
points through a path along which a request is routed and 
forwarded, hopping from one cache to another, to where the data may 
be ultimately found. When a proximal cache is overloaded in Jordan, 
the proximal cache sends the URL request, which is not used as 
routing information, to an alternate cache location, at an 
alternate destination. (See Figure 3) As such, each proximal cache 
monitors the frequency of the requests, and if overloaded, each 
proximal cache searches its caching table directory to find other 
caches storing the same web content data, and forwards the request 
to the alternate source cache. In this manner, load balancing and 
web content data sharing is achieved. 
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Jordan forwards a URL request to a destination source cache, 
being both a destination and a source. Each cache in Jordan is a 
proximal cache, a destination cache, and ultimately a source cache, 
each maintaining a respective like caching table. The communicated 
URL requests or polling inquiries are simply not routing items 
having a tri-ref erenced association between a destination IPA, a 
source IPA, and a URL enabling a migration of forwarding and 
routing tables. The polling in Jordan is a bilateral communication, 
and not a unilateral communication. Jordan does not communicate 
from one proximal cache to a destination cache indicating that data 
is available through, but not necessarily at, yet another source 
cache. Jordan's caches do inquire through multicast polling where 
the information is stored for maintaining the caching table. When 
stored at the destination, the proximal overloaded cache sends the 
URL request to the destination to load share. In Jordan, there is 
no tri-ref erenced associated routing information broadcast from a 
proximal cache to a second destination cache indicating a direct 
forwarding or indirect routing path to where the web data is stored 
on a third source cache. In Jordan, there is no routing information 
whatsoever, but rather, mere requests to send web content data to a 
requester or polling inquiries. In Jordan, an overloaded proximal 
cache searches its caching table directory, and then communicates 
and forwards the request from a proximal cache to a distal 
destination also serving as an alternative source cache. As such, 
Jordan does imply operation among three locations including a 
requester, an overloaded cache, and an underloaded cache. The 
operation in total does involve three locations, a requester, a 
proximal cache, and a destination source cache. However, the 
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information consists of mere requests, inquiries, and does not 
point directly or indirectly to yet another third alternative 
source cache of the web content data. In Jordan, the destination 
and source are one in the same. The requests may be also used as 
the inquiries as to whether or not the web content data is stored 
at a distal cache. Hence, Jordan's communicated information is 
different. For maintaining the caching table, Jordan's information 
may include URL requests, the requester, and the destination, but 
not URL requests, the destination, and another source. The polling 
inquires would not include the alternative source as with the tri- 
referenced associated routing information of claim 1. Jordan 
provides for mere URL requests or inquiries, whereas the present 
invention broadcasts actual tri-ref erenced routing information. The 
information is different, and hence, Jordan does not anticipate, 
and information communicated ultimately serves different purposes, 
such as load sharing using caching tables as opposed to routing 
information migration, and hence, the arguments as to 
nonobviousness . Jordan solves the problem of load balancing using 
forward requests, polling inquires, and caching tables whereas the 
present invention solves the problem of migrating routing tables 
and does so by broadcasting tri-ref erenced associated routing 
information. With different problems solved, different objectives, 
and different solutions, Jordan does not remotely suggest the 
present invention. 



Specifically comparing apples to apples, Jordan teaches 
multicasting where a cooperative cache multicasts URL requests or 
inquiries to other caches. (Col 8 line 1) These URL requests may 
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function as simple inquiries, such as, "do you have this 
information", and the answer may be "yes," indicated by merely 
sending the web content data in response. In so doing, each cache 
polls the remaining caches to maintain the caching tables. Jordan 
maintains a caching table by polling caches through bilateral bi- 
referenced communications. The present invention broadcasts 
unilateral tri- referenced routing information, so that, distal 
caches can maintain routing and forwarding tables. Jordan 
bilaterally multicasts bi-ref erenced unassociated inquires to 
maintain caching tables in proximal caches. The present invention 
unilaterally broadcasts tri -referenced associated routing 
information for maintaining forward and routing tables in distal 
caches. The two processes are completely different serving 
different objectives for solving different problems. 

Jordan is clear and teaches load balancing. "Direct requests 
155 are sent from the clients ... to cache server". (Col 5 line 55) 
"If an actual load imbalance is identified . . . the load monitor 
initiates a shifting of forwarded requests from the overloaded 
cache to ... less loaded servers". (Col 6 line 3) "if the owner is 
currently overloaded . . . the load monitor finds an underloaded 
cache ... and assign it as the new owner of the requested object". 
(Col 6 line 63) "The ownership information for the object in the 
caching table is updated". (Col 6 line 64). "The request can be 
forward ... to the new owner". (Col 7 line 3) 

The examination states that Jordan's request includes source 
address, destination address, forwarding address, next hop address. 
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as disclosed in the request to an arbitrary cache or destination 
upon a cache miss wherein the new entry is created for the object 
in the caching table a routing or forwarding table (Col 6 L50-67, 
and Fig 2a) . 

Is that really so? A search of specification reveals that the 
term "HOP" is not found at all. A search of the summary and 
preferred embodiment reveals that the term "route" is not used at 
all. Yet, to the examiner, it is apparently clear from these 
apparent phantom words. Within this cited text, none of these terms 
are mentioned at all, yet, this section is cited as the basis of 
the rejection. This is remarkable. Applicant appreciates that the 
technology is complex and involves many caches at many different 
locations serving different uses while communicating different 
types of information. Nonetheless, precise and careful reading is 
required to fully understand the differences between Jordan and the 
present invention. 

The caching table shown in Fig 2a of Jordan includes objects 
(the URL) and "Ownership" that is, the caches A, B, C storing the 
web content data. Such specific A, B, and C caches are not 
arbitrary, as indicated by the examiner, but indicate exactly where 
the data can be found and exactly where the request can be 
forwarded for load balancing and sharing. It appears the examiner 
reads more in Jordan than what is really there. 

The plain full text does not read as the examiner indicates. 
"FIG. 3 shows an example of a logic flow for steps taken by the 
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load monitor 120 in response to a request 125 from a cache server 
150 because of a cache miss. As depicted, in step 201, it checks to 
see if the requested object/partition can be found in the caching 
table. If not, in step, 202, a new entry is created for the 
object/partition and a cache server is assigned as its owner. After 
the entry is located in the caching table, in step 203, the 
forwarding frequency 1011 is updated, e.g., incremented by 1. The 
load monitor then examines the load table 102 to see if the owner 
is currently overloaded (and that the forwarding frequency 1011 is 
a significant contributor thereto), in step 204. If yes, in step 
205, the load monitor finds an underloaded (or less loaded) cache 
server and assign it as the new 10122 (or shared) owner 10122 of 
the requested object. The ownership information 1012 for the object 
in the caching table 101 is updated accordingly. Those skilled in 
the art will appreciate that the logic flow could comprise a shared 
10123 or hierarchical ownership 1012 in the caching table 101 or 
other data structure employed. The request (possibly with a copy of 
the requested object) can then be forwarded 125 to a new sole 10122 
(or shared 10123) owner, in step 206. Alternatively, the new owner 
can be requested to obtain 115 an object copy from the originating 
object server, e.g., via the Internet 110." (Col 6 lines 50-66). 

As such, the examiner incorrectly cites a specific section of 
text standing for the proposition that "On the other hand, Jordan, 
in its clear context, explicitly teaches the process of 
transmitting routing information, (such as source address, 
destination address, forwarding address, next hop address, as 
disclosed in the request) to an arbitrary cache or destination upon 
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a cache miss, wherein the new entry is created for the object in a 
caching table, or routing or forwarding table." In discussing 
Jordan, "in its clear context", the examiner uses the terms such as 
"source address", "destination address", "forwarding address", 
"forwarding table", yet a simple cursory examination of the cited 
text upon which the examiner relies, teaches no such things nor 
uses any of these terms. Where are these terms in the cited text? 
How possibly could one make this apparent leap, but through some 
kind of tortured reasoning? These terms used by the examiner are 
not in the cited text, nor suggested in any regard, yet asserted by 
the examiner, as "clear". This is remarkable. The record of the 
present prosecution is becoming so distorted by the examiner's 
unsupported assertions, that this record is quickly becoming, in 
and of itself, a strong indicator of nonobviousness . 

Jordan should be viewed from the exclusive perspective of a 
lone proximal cache, as dictated by the structure of claim 1 of the 
present invention. Jordan multicasts different information, that 
may be simple URL requests indicating a requester and the URL to a 
source of the URL data. This is opposed to broadcasting routing 
information associating an alternative source and a URL with a 
destination IPA, which does not even request the URL data. In 
Jordan, the URL request is communicated to a different location, 
that is, directly to a source of URL web content data for 
retrieving the URL content data. This is opposed to communicating 
to a destination cache that merely receives the routing information 
indicating an alternative source, which communication can then be 
used to build a forwarding and routing table. Jordan solves a 
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different problem that is one of load balancing among like caches. 
This is opposed to solving the problem of migrating routing 
information for the purpose of building routing and forwarding 
tables in different arbitrary distal caches. With all kind due 
respect, Jordan does not remotely suggest the prevent invention. 

Jordan multicasts polling bi- referenced inquiries from a 
proximal cache to destination caches that affirmatively respond in 
bilateral communications for maintaining a caching table in the 
proximal cache , which caching table is then used for forwarding URL 
requests to those destinations storing the URL data when a URL 
request frequency at the proximal cache is high for load balancing . 

The present invention of claim 1 broadcasts from the proximal 
cache to destination caches tri- referenced routing information in a 
unilateral broadcast communication, where the routing information 
associates a source IPA with stored originating URL data or stored 
additional routing information to a source of stored URL data along 
with the destination IPA, so as to enable the maintenance of 
forwarding and routing tables in the destination caches as in 
claims 19 and 20. 

Jordan relies on like caches all with like caching tables and 
with like frequency monitoring, whereas the proximal cache of claim 
1 and the distal cache of claims 19 or 20 rely on a cooperation 
between differently operating types of caches. Jordan does not 
suggest such a bifurcated cache function. The present invention is 
not required to poll other caches . The present invention does not 
require load monitoring. The present invention does not require 



-34- 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 



multicast bilateral communications. The present invention does not 
maintain limited caching tables restricted to a few caches for 
simple load sharing only among them through forwarding URL 
requests. The present invention enables the building of generalized 
routing and forwarding tables in arbitrary destination distal 
caches regardless of what web data is stored on the distal 
destination caches. The present invention enables cooperative 
caching about a network of cooperative caches without regard to the 
frequency of URL requests at any one cache. Jordan does not have 
these benefits. The alternative distal source cache may store and 
source the URL web content data through directed forwarding 
requests or the alternative distal source cache may indirectly 
point through hop routing to yet another more remote distal 
alternative source cache storing the URL web content data, as 
indicating the equivalence between forwarding and routing, enabling 
any number of routing hops to locate the sought after web content 
data stored in any one of any number of cooperative caches disposed 
anywhere within a network. The present invention is a significant 
advancement in the art and enables a comprehensive generalized 
network-wide distributive caching solution. 

The cited references do not teach or remotely suggest 
broadcasting of tri -referenced associated routing information from 
a proximal cache to a destination distal cache, with the routing 
information associating URL web content data at an originating URL 
with an alternative distal source cache. The tri-ref erence routing 
information minimally includes: 1) Source IPA (where the web 
content data is cached) ; 2) Origination URL (identifying the 
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original web content data); 3) Destination IPA (where the source 
IPA and Originating URL association are communicated for building 
at the destination IPA routing and forwarding table that directly 
or indirectly point to the URL web content data at the source IPA) . 
The proximal IPA is a fourth bit of routing information. However, 
sometimes the proximal cache and the source cache are one in the 
same. When the destination cache receives this routing information, 
associating the original URL with the source IPA, a routing can be 
created in the destination cache associating the source IPA with 
the originating URL, so that, when a URL request is received by the 
destination cache, the destination can forward (or reroute) the 
request using the association between the request's URL to the 
source IPA, rather than the originator at the originating IPA 
originally storing the web content data indicated by the 
originating URL. Hence, the tri- referenced information can be used 
to build a routing table in a destination cache. When the proximal 
cache at the proximal IPA broadcast the routing information to many 
destination caches, the network of cooperative caches can each 
build a forwarding and routing table for improved web 
communications. Such broadcasting of this specific tri-ref erenced 
associated routing information then enables the maintenance of 
forwarding and routing tables in arbitrary destination caches for 
forwarding and routing URL requests about a network of cooperative 
caches. Allowance of the claims is requested." 

END OF APPLICANT'S PRIOR RESPONSE. 
Examiner's Rebuttal and Applicant's Response 
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a) The examiner states that a knowledge of the invention is 
necessary for the examination and that examination involves a 
reconstruction analysis from prior art elements. To be sure, the 
invention must be in mind, and prior art elements can be found, as 
is most usual, but, it is the cherry-picking of elements based 
solely upon the claims, and then the unfounded combination of them 
along the lines of the invention, that is forbidden, as the 
forbidden reconstruction comes when the examiner, WITHOUT ANY 
SUGGESTION to do so, rearranges prior art elements and combines 
them along the lines of the invention to meet the invention. Where 
is the suggestion in the prior art to associate the specific tri- 
reference routing information? There is none. 

b) The examiner disagrees that Jordan and Garcia do not communicate 
tri-ref erenced routing information. This is a remarkable assertion, 
and clear point of factual difference. The claims just do not cover 
the communication of the tri-ref erence routing information randomly 
at unknown times in bits and pieces, to unknown recipients, for 
some other purposes, but the association of the information 
together, called a forwarding and routing item, and then the 
specific relative communication of the routing item to a relative 
destination that is relative to the source, proximal cache, or 
originator. It is the sum total including: the association of the 
particular tri-ref erence information, the communications of the 
tri-ref erence routing information; and the communication to a 
relative destination. Surely, caches are networked and routing 
information has been used, but not this association relatively 
communicated for the purpose of building remote forwarding and 
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routing tables. The claim is rejected based upon obviousness and 
not anticipation, and hence, there must be shown some motivation to 
combine along the lines of the invention. Jordan and Garcia do not 
teach any motivation whatsoever to combine the information and 
communicate the information to a relative destination as referenced 
by the information. The combination of claim 1 is useful and not 
suggested in the cited references. 

c) The applicant, in dependent claims 19 and 20, set forth the 
application of claim 1, that is, the motivation for so transmitting 
the information to remotely build forwarding and routing tables. 
The examination states that Jordan in view of Garcia discloses the 
process. This is remarkable. Jordan discloses means for simple 
caching and Garcia discloses means for building routing tables. It 
is the Examiner's incorrect conclusions that Jordan in view of 
Garcia "suggests" the inventions. But, there are no suggestions to 
cherry-pick, as the examiner as done, the specific information for 
association and then communicate the same, for the purpose of 
building a forwarding and routing table in a remote destination, an 
application of neither Jordan or Garcia. Hence, the combination can 
not possibly be suggested. 

d) The examiner disagrees that other caching systems do not 
broadcast tri -reference information. Caching systems cache data. 
The present invention of claim 1 is not concerned about caching 
data, as that has already been done on the network, but rather, 
building remote forwarding and routing tables through propagating 
associated forwarding and routing information to access that cached 
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data, and therein lies the problem with which the examiner 
incorrectly draws unsupported conclusions. It is the specific 
association, as claimed, the forwarding and routing information 
communication, as claimed, and the relative destination, as 
claimed, being relative to the originator, source, and the proximal 
cache, that is novel, as a whole, that then enables the creation of 
remote forwarding and routing tables. That is, the claim must be 
read as a whole. Surely, all of this information has been 
communicated before in bits and pieces, and surely, networked 
caches are very well known, and surely, routing and forwarding 
tables have been used, but that is not the point. The focus of the 
examination should be on the association of particular information 
and the particular relative communication, and not any association 
or any information, communicated between any cached elements for 
various other purposes. It is the particular set of tri-ref erence 
associated information and the particular relative positions of the 
caches that, as a whole, is the core novel part of the invention 
that is recited in claim 1. 

The examiner states "claim 1 simply associates the source IPA 
and the originating URL and transmits this information." This is a 
remarkable reduction of the word count of claim 1, and apparently 
misses the point of the particular tri-ref erence information and 
the communications between the proximal cache and the destination, 
relative to a caching source and a URL originator. Perhaps 
applicant can be of some assistance. Claim 1 includes communicating 
the source IPA and originating URL, which communication includes 
associating the proximal sender as identified by a proximal IPA and 
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associating the destination identified by a destination IPA. Hence, 
the association includes the source IPA, URL, proximal IPA, and 
destination IPA. Because the source cache and the proximal cache 
can be one in the same, as in claim 3, the tri-ref erenced 
information includes at least the source IPA, URL, and destination 
IPA, forming a forwarding and routing item, all associated together 
and communicated in association in a packet from the proximal IPA 
to the destination IPA whereat a table can be reconstructed. 

Claim 1 particularly recites: 

generating at the proximal IPA 

an originating URL (indicating an originator) , 

generating at the proximal IPA 

a sourcing IPA for (indicating a source) , 

generating at the proximal IPA 

a destination IPA for indicating a destination cache, 
associating at the proximal IPA 

the sourcing IPA and the originating URL as the routing 
information, and 

transmitting the forwarding and routing information from the 
proximal cache at the proximal IPA to the destination cache at a 
destination IPA, the transmitting of the forwarding and routing 
information associates the sourcing IPA the originating URL with 
the destination IPA. 



/// 
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In claim 1, there is: 

1) an originator, (cache) ; 

2) an originating URL (information and not a request) ; 

3) a source IPA (routing information) 
(indicating a source cache) ; 

4) a proximal cache (cache) (which may be the source cache) ; 

5) a proximal IPA (information) ; 

6) a destination (cache) ; 

7) a destination IPA (information) ; 

Here, the forwarding and routing information is associated and 
relatively communicated. Just because this information, caches, and 
tables are known, in bits and pieces in the prior art, does not 
make the particular association and the particular relative 
communication combination, that is, the claim as a whole, obvious. 

e) The examiner indicates that the argument upon which the 
applicant relies are not found it the claims. Justly so, arguments 
are not supposed to be appended to the claims. Obviousness is 
determined by the solution as claimed, and the problem solved, 
which may not be claimed. The problem solved involves old problems, 
new applications, new uses, and new motivations, which problems and 
applications need not be recited in the claims, yet they provide 
reasons why the claimed combination solution is not obvious. Hence, 
the problem solved and new application arguments need not be in the 
claims, as it is enough that the claimed combination, the solution, 
not be suggested and be useful. The examiner is wrong. Arguments 
and problems solved need not be recited in the claims. 
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The specification teaches, and, the inventions of claims 19 and 
20 set forth, the application and the purpose, a problem solved, of 
the association and relative communication. The reasons why an 
invention is not obvious need not and should not be found in the 
claims. Rather, the claims recite the cooperative elements 
performing a useful function. The associated information and 
relative communication has the useful purpose of being able to 
migrate tables, the purpose of claims 1 and 21, and the function 
invention of claim 19. The purpose, not claimed as such, of claim 
19 is to perfect a network of cooperative caches with the 
functional migrated forwarding and routing tables, even though a 
network of cooperative caches is not claimed in claimed 19, nor 
must it be so claimed. The examiner found that these combinations 
are not anticipated, hence, the obviousness arguments. But, 
arguments are just that. Here, the specific association and 
relative communication are not suggested in the cited reference, 
even though, as is common, all of the elements are found in the 
prior art somewhere, in bits and pieces. The claimed combination 
has a useful purpose, even though that purpose may not be recited. 
The purpose and application of the invention of claim 1 need not be 
claimed. It is sufficient that claim 1 be useful, which it is, 
because it enables table migration, that it is not anticipated, 
which has already been found by the examiner, and that it not be 
obvious, which it surely is not obvious, as there are no 
suggestions in the cited references to combine forwarding and 
routing information and relative communication along the lines of 
the invention. 
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Where is the suggestion in Jordan and Garcia to associate the 
specific information with relative communication for the purpose of 
migrating a forwarding and routing table to a remote cache? There 
is simply none. What is missing is the motivational purpose of 
migrating routing tables using the associated information and 
relative communications, as in claim 1. There is no teaching or 
suggestion that this information, so associated and communicated, 
could be used to migrate forwarding tables. The applications and 
purposes of Jordan and Garcia are different. There are no 
suggestions anywhere to modify Jordan and Garcia, inconsistent with 
their teachings, information, communications, and purposes to 
arrive at the claimed invention, and where, as here, an applicant 
proceeds contrarily, with a different set of data, differently 
communicated through different routes to different relative 
entities, for achieving a different purpose, it is strong evidence 
of nonobviousness . 

Claims 19 and 20 set forth the application of the tri- reference 
association and relative communication in the context of their 
purpose, and that is, to create a distally located forwarding and 
routing table. Claims 19 and 20, in addition to claim 1, require 
the specific tri-ref erenced association, the specific relative 
communications, and, per claims 19 and 20, for the specific purpose 
of migrating forwarding and routing tables to be built in a cache 
per that relative communication. Yet, despite this specific 
association, this specific relative communication, and this 
specific table building purpose and function, the examiner 
concludes it is all obvious, without a suggestion to do so. It is 
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not that Jordan communicates information or that Garcia builds a 
table, but rather, do they in combination, suggest this specific 
association, this specific relative communication, and this 
specific table building purpose and function. 

f) The examiner disagreed that Jordan does not teach a method of 
reconstructing a table. Not any table will do. A caching table 
indicates the local cache stores the data. A routing table 
indicates routes from one router to the next. A forwarding table 
indicates what other cache store the table to which a request can 
be sent. Caching and routing tables are different from forwarding 
tables. Just because Jordan communicates some caching information 
to some destination for indicating a cache source using a caching 
table, does not mean that Jordan suggests this specific 
association, this specific relative communication, and this 
specific forwarding and routing table building purpose and 
function. Jordan builds a caching table locally from received URL 
requests and not from forwarding and routing items. Jordan builds 
caching table and not a forwarding and routing table. The examiner 
states that "the request as in Jordan includes the association of 
source with a URL to an arbitrary destination because the request 
includes destination address, source address, URL." Jordan does 
not send an associated URL as forwarding and routing information, 
but rather sends a URL request, requesting the URL data. Claim 1 
refers to an originating URL, which is information, whereas Claim 
19 refers to a URL request, which is an instruction. A URL as 
associated forwarding and routing information is different from a 
URL request, which is a functional request for Web data. 
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In Jordan, a proximal cache at a proximal IPA receives a request 
for URL web content data from a client browsing requester. When the 
proximal cache at the proximal IPA is overloaded, the proximal 
cache redirects the URL request to a destination IPA that will be 
storing the URL web content data. That is, the URL request is 
merely forwarded to an alternative source, the destination at the 
destination IPA. The URL request contains an association between 
the requesting IPA and the URL request of the URL originator at an 
originating IPA originally firstly storing the requested URL web 
content data. Then, the destination cache stores the web content 
data to serve the URL request. The destination retrieves the URL 
web content data, stores it locally, and updates its caching table, 
which is not a forwarding table, but a caching table indicating 
that the URL data has been locally stored. No forwarding is 
contemplated by the destination having the stored URL data. Hence, 
Jordan teaches load sharing and maintains local caching tables 
using URL requests. 

So, in claim 1, when forwarding and routing information is to 
be propagated about a network of cooperative caches, a proximal 
cache at a proximal IPA sends a source IPA indicating a source 
storing URL web content data and sends a URL indicating an 
originator at the originator IPA, and in so doing, necessarily 
sends in association the proximal IPA and the destination IPA as a 
quad-reference association of forwarding and routing information, 
whereas, in Jordan, when a proximal cache, that is also a source 
cache, at a proximal source IPA storing the URL web content data is 
over loaded by a URL request from a browsing requester at a 
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requesting IPA, the proximal source cache sends the URL request to 
the destination, which will first download the URL web content 
data, update its caching table, and communicate the URL web content 
data to the requester. No forwarding tables are built. 

Garcia teaches that each router maintains a plurality of 
labeled routing trees (LRTs) , each LRT corresponding to a type of 
service of the computer network, wherein the LRTs of routers in the 
computer network are updated in response to receipt of one or more 
routing state update messages and wherein LRTs are updated 
according to whether an optimum routine approach or a least 
overhead routing approach is used within the computer network, the 
optimum routing approach routing state update messages are 
transmitted when at least one of: (i) a routing state update 
message which causes a link to be added to a subject router's 
labeled routing trees is received, (ii) a recent routing state 
update message regarding an existing link in the subject router's 
labeled routing trees is received, and (iii) a destination becomes 
unreachable by the subject router. 

When a router table has changed upon receipt of a message, the 
routing tree is updated. The routing state update messages include 
a link- state information and a node- state information, wherein each 
router maintains a plurality of labeled routing trees (LRT) . Any 
message transferred between a proximal and destination router has 
the respective IPAs. A protocol allows for the dissemination of 
link-state information and node-state information in the form of 
labeled routing trees (LRTs) . Updated routing trees in a routing 
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state update messages are used to communicate changes in the 
routing network topology. Garcia, while computing hops, as is 
expected with routers, does not relate to URLs, and does not relate 
to finding alternative sources of URL web content data, because 
Garcia was not concerned with migrating forwarding tables that 
indicate where Web content data can be found. Forwarding tables are 
used to route requests to sources of data whereas routing tables 
are used for determining routing paths for routing requests. 



/// 
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Claim 1, Jordan, and Garcia Comparison Chart 



Claim 1 



Jordan 



Garcia 



Routing Table 
Migration 

Source IPA 
Proximal IPA 
URL data 
Destination IPA 

Communicating 
a routing item 



Load 

Balancing 



Routing Tree 
Maintenance 



Source&Proximal IPA Proximal IPA 
URL Request 

Destination IPA Destination IPA 



Communicating 
a URL request 



Communicating 
a routing tree 
change message 



for building 
routing and 
forwarding tables 

for distributive 
migration of 
forwarding and 
routing tables 



for building caches, for updating a 
caching tables, and routing tree 
serving URL requests table 



for distributive 
creation of caches 



for network 
routing topology 
connec t i vi ty 
maintenance 
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Garcia does not relate to a URL or to a forwarding table, and 
does not provide for the migration of forwarding tables. Garcia 
does not send a forwarding and routing item, but rather sends in a 
message, a complete routing tree. Garcia does not send URL 
identifiers or source IPA routing data, as the web content data is 
not even addressed. Garcia does not send associated data for 
updating forwarding and routing tables, but rather sends update 
routing tables as the message is irrespective of any web content 
data. 

Jordan was concerned with network load balancing using caching 
tables and communicated URL requests. Garcia was concerned with 
routing topology updating using updated routing trees and messages 
that communicated the updated routing trees. How possibly can these 
two things be combined in any way when they are inherently directed 
to different teachings and purposes, and not directed to migrating 
forwarding tables where web content data can be found. One can only 
guess. However, in so guessing, when a cache has both an internal 
caching table as in Jordan and an internal routing table as in 
Garcia, a process could be locally used to translate Jordan's 
caching table indicating where the web content data is stored and 
Garcia 1 s routing table indicating paths to various routers, into a 
forwarding and routing table locally, but that would not be 
migration by broadcast, but local generation, as is common in the 
art, and hence, would not reach the claimed invention. In guessing 
again, Jordan's URL request could be sent to Garcia 's router that 
would then not view the URL request as a request, inconsistent with 
Jordan's teachings, but rather, view the URL request as URL data 
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and translate Jordan's proximal IPA as a source IPA, and then 
update Garcia' s routing table into a forwarding and routing table, 
which would be inconsistent with Garcia 's teaching of sending 
updated routing trees and would also be locally generated and not 
migrated. Simply put, there is no suggestion to 1) treat Jordan's 
URL request as a URL identifier inconsistent with Jordan's 
teachings, 2) use Jordan's proximal IPA as the source IPA 
inconsistent with the clear language of claim 1, and 3) thirdly, 
modify Garcia' s routing table as a forwarding table using the URL 
request not as a request but as a routing item for building a 
forwarding table inconsistent with Garcia' s messages, which, even 
if done under extreme reasoning, would still not reach the claimed 
invention, as claim 1 recites both a source and a proximal cache. 
The combination of Jordan and Garcia would still not reach the 
claimed invention even when reasonably combined according to their 
teachings . 

There is no suggestion in the cited references to construe 
Jordan's URL request as a URL routing item, to associate Jordan's 
URL request with another source IPA, to communicate Jordan's URL 
request as part of a forwarding and routing item communicated 
between a proximal cache and a destination cache, to use a source 
and a proximal cache IPA both as Jordan 1 s proximal cache for 
storing the web content data, to generate a wholly new process that 
would translate Jordan's URL request into a forwarding and routing 
item, and to translate Garcia 's routing table into a forwarding and 
routing table. 
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g) The examiner again asserts that the "receiving unilateral 
broadcast tri -reference associated routing information are not 
recited." Again, the examiner contends that the exact language of 
arguments must be recited in the claims. No, they do not. The claim 
must have an unobvious useful combination in view of cited 
references, and no more. Argument as to why the combination is not 
obvious need not be recited in the claims. Claim 1 does recite the 
tri -reference association and does recite only one communication 
that is from the proximal IPA to the destination IPA, and no other, 
which is, by definition, a unilateral communication. As the 
destination is arbitrary, but relative, and the communication of 
claim 1 can be repeated, and hence, practicing the invention of 
claim 1 more than once, is inherently a broadcast. 

Importantly, the examination effectively asserts that because 
routing information, routing tables, caches, and caching tables are 
known, the specific association, and the specific relative 
communication, in combination, would be obvious, irrespective of 
any application. This is wrong. Yet, when one considers the 
specific purpose, the application, as in claim 19 and 20, the 
examiner again finds that the application is suggested as well, but 
without a suggestion to do so. 

h) The examiner states that the application relies upon a 
unilateral communication. Yes, claim 1 is directed to a unilateral 
communication, whereas Jordan requires bilateral communications. 
This difference supports nonobviousness, in that, a unilateral 
communication can be used for a purpose other than Jordan's 
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purpose. If Jordan and the present invention have different 
applications, different purposes, different information, and 
different relative communications, how possibly can it be suggested 
to modify Jordan, by its own text, inconsistent with its teaching 
for another purpose to arrive at the present invention of the 
associated information and relative communications? It cannot. 

i) The examiner refers to the prior art to Jordan using various 
terms. One problem with this examination has been its inability to 
examine invention vis-a-vis similarly disposed components. Hence, 
the need to keep in mind, the specific associations and relative 
communications . 

While it is true that routing information is known, distributed 
caches on a network are known, and that routing tables are known, 
there is no suggestion in the cited references to use these 
specific tri-ref erence associations and the relative communication, 
that would then enable the migration of forwarding and routing 
tables about a network of cooperative caches. The claims being in 
good condition for appeal, allowance of the claims is requested. 
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